This PR adds a full legacy .eslintrc.cjs alongside the existing flat eslint.config.js configuration. With ESLint v10 (as pinned in package.json), eslint.config.js is the active config and .eslintrc.* is typically ignored unless users opt out of flat config. Consider removing this file or documenting why it’s needed to avoid confusing contributors with two independent ESLint configurations.

Agree, why we need this new eslintrc file?

Sorry, this was a mistake.

I think range should be always at end.

  decorators: DecoratorNode[] | null,
  range: Range,
): ParameterNode {

And yes, this will lead to more refactorings

All set. 👍

This is quite a lot of code (almost a complete AST pass) for a relatively simple feature. There's probably a more compact and general approach that can take its place, like during an earlier pass maintaining a set of references to decorators (or decorator-containing parents if necessary), and after initalize walk just this set to see what remains. Otherwise, if we did it like this, we'd ultimately end up with a bunch of adhoc passes eventually, that all need to be updated whenever the AST changes.

Btw I also thought it would be better to extend the existing methods for parsing decorators. We could add a boolean operator to indicate that it is indeed a parameter. Although we need to assess how much overlap there is. @jtenner have you considered that opportunity?

Im unsure what @MaxGraey means, but I think this should be consolidated instead of added as a pass now that I look at it. Any ideas?

Thanks, I took this route in 6f75b5e.

Instead of keeping a bespoke recursive pass in Program, I split the problem into three parts:

1. parser.ts records which source-level statements actually preserved parameter decorators while parsing,
2. ast.ts owns subtree traversal through a small shared NodeWalker, and
3. program.ts now just runs a tiny parameter-specific validator after afterInitialize.

The main reason I chose this approach was to get AST topology knowledge out of Program and into one shared traversal utility, so we do not keep accumulating feature-specific recursive passes there as the AST evolves. That seemed like the best way to address the maintainability concern you raised while still keeping the transform timing/behavior the same.

If you would prefer this to validate by walking all sources after afterInitialize, or if there is a better place/shape for the walker, I am happy to adjust. Any feedback or suggestions would be appreciated.

It is among the more usable fictions of the present moment that cognition itself can be cleanly externalized into an adjacent intelligence, though the very convenience of that displacement is precisely what renders it corrosive: one entrusts thought to the apparatus only to discover, in the flattening light of that delegation, the full contour of one's accumulated judgment already exposed, already spent, already standing outside itself.

It's literally very similar to serializeDecorator. I suggest combining this such similar methods for other parts into a single one serializeDecorator (or visitDecorator), and accounting for the difference in logic with an optional second parameter

All set. 👍

By the way, thank you for explaining. It wasn't clear to me what you meant, and this was good feedback!

I think there’s something similar somewhere else. Try to investigate more. Also, you could delegate this to LLM with good reasoning

For example, I think it's a good candidate

A good candidate for what?

It used only once. It could be inclined I guess. Or this already has some helper. I don't remember

Can you make a suggestion please? I'm sorry I don't understand.

parseParameterDecorators has only one usage and quite small. Why we need parseParameterDecorators function? Just manually inline it

All set. 👍

Why do we need a NodeWalker? And why we can't do validation after finishing parsing of decorators?

If you do parsing of the decorators they need to survive to become transformed. If they exist after the transform phase, that is when validation should kick in.

Unless I misunderstand how things work?

No, it has usually done via "error parser recovery" mechanics. As far as I can recall, AssemblyScript also follows this approach to some extent. The idea is that you carry on parsing: if you encounter an error, for example missed closing bracket, you're print the error and close bracket by yourself, then continue parsing

@MaxGraey If there is a parsing error, does a transform still work?

Why should transform work if we can't properly parse decorators?
As I already said, the parser is designed in such a way that it doesn't stop if errors occur. It tries to fix everything automatically and continue parsing. So, theoretically, you can pass incorrect AST to transformer for instance. But why?

For context: The general idea behind the design is that one parse discovers all the parse errors in one go, instead of failing early, and only discovering more as one fixes the source. Is for diagnostics, not implying that when there is a parse error, the source is actually attempted to be compiled.